[discuss] Enables to resolve direct pom dependencies (not transitive ones) location as project.dependencies. reference - eases javaagent usage for ex - #1281

So the idea is that a given group and artifact ID gets resolved to the following property:

${project.dependencies.com.bar.dummy-agent}

Only disadvantage of your solution: I don't see where the groupId ends and the artifact ID begins. But that's probably not going to clash.

This is very helpful for agents.

Other ideas:

Change the default lifecycle XML to include the property goal of the dependency plugin. Way smaller change.

I forgot this file doesn't exist anymore.

https://github.com/apache/maven/blob/maven-3.3.8/maven-core/src/main/resources/META-INF/plexus/default-bindings.xml

But I think you get what I'm referring to.

If it clashes we have other troubles and using another sep looks wrong in placeholders to me.
Im also very hesitant to add another plugin in any lifecycle cause:

1. It is specific to default lifecycles
2. Adds another prerequisite and i tend to think we already have too much
3. It will be too late in the interpolation and need other passes

Thank you for the explanation, that makes excellent documentation! 😃

This really looks like a temporary hack for agents to being supported by Surefire...
It only saves the following declaration:

 <plugin>
    <artifactId>maven-dependency-plugin</artifactId>
    <executions>
      <execution>
        <goals>
          <goal>properties</goal>
        </goals>
      </execution>
    </executions>
  </plugin>

Well any later phase is wrong cause then it depends if the interpolation will be reprocessed or not so think it is the least bad compromise to work immediately but agree on your point, the limitation is to explicit define the dependency in the project (potentially using a property but without anything implicit).
I'm fine dropping this PR if it does not help while we don't add dependency plugin in any default lifecycle.

Well any later phase is wrong cause then it depends if the interpolation will be reprocessed or not so think it is the least bad compromise to work immediately but agree on your point, the limitation is to explicit define the dependency in the project (potentially using a property but without anything implicit). I'm fine dropping this PR if it does not help while we don't add dependency plugin in any default lifecycle.

@rmannibucau Wouldn't it be better to enhance the PluginParameterExpressionEvaluatorV4 class instead ?

@gnodet I'm mixed about it since it assumes everything is wired in plugins conf and plugins/extensions don't read any other property so not sure it is really better today, maybe let's wait to see what mockito picks?

solved in maven 4